🚀 go-pugleaf

W dniu 21.03.2022 o 15:28, Kamil pisze:
> Witam
> 
> Postanowiłem napisać programik konwertujący polskie "pliterki" z txt 
> ASCII na UTF 8. I coś mnie zaniepokoiło. Otóż znaki te w UTF 8 maja na 
> końcu średnik. A o ile dobrze pamiętam sam średnik i wszystko za nim 
> jest traktowane jako komentarz i pomijane. Dobrze sądzę?
> 
> Pozdrawiam

Witam.

Ogólnie - tak, "wolnostojący" średnik w asemblerze jest początkiem 
komentarza, ale to nie przeszkadza używać go w napisach czy komendach:

	napis db 'a;b;c'

	mov al, ';'

Natomiast znaki "ąćęłńóśźż" kodują się w UTF-8 na wartości szesnastkowe

	C4 85 C4 87  C4 99 C5 82  C5 84 C3 B3  C5 9B C5 BA  C5 BC

Tutaj średnika nigdzie nie ma i to jest ta część problemu, której za 
bardzo nie rozumiem. Chyba że masz na myśli np. encje HTML postaci 
"&#C485;", to wtedy wracamy do używania średnika w stałej znakowej i 
to powinno bez problemu działać.

-- 
Pozdrawiam/Regards - Bogdan                     (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux):            http://bogdro.evai.pl
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.Xiph.org www.TorProject.org  Soft(EN): http://bogdro.evai.pl/soft

Użytkownik "Bogdan (bogdro)"  napisał:

>> Postanowiłem napisać programik konwertujący polskie "pliterki" z txt 
>> ASCII na UTF 8. I coś mnie zaniepokoiło. Otóż znaki te w UTF 8 maja na 
>> końcu średnik. A o ile dobrze pamiętam sam średnik i wszystko za nim jest 
>> traktowane jako komentarz i pomijane. Dobrze sądzę?

> Ogólnie - tak, "wolnostojący" średnik w asemblerze jest początkiem 
> komentarza, ale to nie przeszkadza używać go w napisach czy komendach:

> napis db 'a;b;c'

> mov al, ';'

> Natomiast znaki "ąćęłńóśźż" kodują się w UTF-8 na wartości szesnastkowe

> C4 85 C4 87  C4 99 C5 82  C5 84 C3 B3  C5 9B C5 BA  C5 BC

> Tutaj średnika nigdzie nie ma i to jest ta część problemu, której za 
> bardzo nie rozumiem. Chyba że masz na myśli np. encje HTML postaci 
> "&#C485;", to wtedy wracamy do używania średnika w stałej znakowej i to 
> powinno bez problemu działać.

Bardzo serdecznie Cię witam i pozdrawiam. Dawno się nie czytaliśmy :)

Chodzi o moją stronkę zawierającą ledwie kilkanaście wierszy tekstu i 
odnośniki do ewentualnych plików. Na dobrą sprawę kilka znaków mógłbym 
wstawić "na piechotę", ale postanowiłem utrudnić sobie życie i napisać 
program. A, że dawno to robiłem, więc prawie wszystko zapomniałem.

Do rzeczy. Piszę z komputera z WIndows 7, więc pewnie program się na nim nie 
uruchomi. Przejdę na sprzęt z XP i tam będę walczył. A póki co pewne rzeczy 
mi się nie zgadzają. Kody podane przez Ciebie są inne niż ja mam. Rzuć okiem 
na:

http://kamil100.refy.pl/Pliki/UTF%208.jpg

Pozdrawiam 

W dniu 22.03.2022 o 15:27, Kamil pisze:
> Użytkownik "Bogdan (bogdro)"  napisał:
> 
>>> Postanowiłem napisać programik konwertujący polskie "pliterki" z 
>>> txt ASCII na UTF 8. I coś mnie zaniepokoiło. Otóż znaki te w UTF 8 
>>> maja na końcu średnik. A o ile dobrze pamiętam sam średnik i 
>>> wszystko za nim jest traktowane jako komentarz i pomijane. Dobrze 
>>> sądzę?
> 
>> Ogólnie - tak, "wolnostojący" średnik w asemblerze jest początkiem 
>> komentarza, ale to nie przeszkadza używać go w napisach czy komendach:
> 
>> napis db 'a;b;c'
> 
>> mov al, ';'
> 
>> Natomiast znaki "ąćęłńóśźż" kodują się w UTF-8 na wartości szesnastkowe
> 
>> C4 85 C4 87  C4 99 C5 82  C5 84 C3 B3  C5 9B C5 BA  C5 BC
> 
>> Tutaj średnika nigdzie nie ma i to jest ta część problemu, której za 
>> bardzo nie rozumiem. Chyba że masz na myśli np. encje HTML postaci 
>> "&#C485;", to wtedy wracamy do używania średnika w stałej znakowej i 
>> to powinno bez problemu działać.
> 
> Bardzo serdecznie Cię witam i pozdrawiam. Dawno się nie czytaliśmy :)

  :)

> Chodzi o moją stronkę zawierającą ledwie kilkanaście wierszy tekstu i 
> odnośniki do ewentualnych plików. Na dobrą sprawę kilka znaków mógłbym 
> wstawić "na piechotę", ale postanowiłem utrudnić sobie życie i napisać 
> program. A, że dawno to robiłem, więc prawie wszystko zapomniałem.


  Dobre ćwiczenie, też sobie kiedyś zrobiłem program związany z 
kodowaniami (tylko ten zamieniał polskie znaczki na ich odpowiedniki 
ASCII).


> Do rzeczy. Piszę z komputera z WIndows 7, więc pewnie program się na 
> nim nie uruchomi. Przejdę na sprzęt z XP i tam będę walczył. A póki co 
> pewne rzeczy mi się nie zgadzają. Kody podane przez Ciebie są inne niż 
> ja mam. Rzuć okiem na:
> 
> http://kamil100.refy.pl/Pliki/UTF%208.jpg


  Aha, i tutaj mamy niby subtelną, a jednak sporą różnicę między czymś 
o nazwie "UTF-8" a czymś o nazwie "Unicode".
  Co ja zrobiłem, to po prostu, bez zagłębiania się w jakikolwiek 
normy, wpisanie na terminalu w kodowaniu UTF-8 (tak, Linux):
	echo ąćęłńóśźż > aaa
  i obejrzenie wynikowego pliku hex-edytorem. Stąd wartości bajtów. I 
tak, to jest UTF-8.

  Różnice w tym, co dostaliśmy polega na tym, że ty patrzysz na coś, 
co się nazywa Unicode (https://en.wikipedia.org/wiki/Unicode, 
https://en.wikipedia.org/wiki/Universal_Coded_Character_Set), a ja na 
UTF-8, czyli tylko na jedno z kodowań standardu Unicode.
  Unicode mówi z grubsza, jaki dany znak ma numer. UTF-8, UTF-7, 
UTF-16, UTF-32 i jakie tam jeszcze inne kodowania da się znaleźć, są 
właśnie tym - kodowaniami, czyli sposobami, w jaki znak o numerze X w 
Unicode, zostaje przetworzony na faktyczne bajty.
  Oba nasze zestawy liczb są np. tutaj: 
https://pl.wikipedia.org/wiki/Kodowanie_polskich_znak%C3%B3w i można 
to sobie porównać.

  Teraz patrzę na normę HTML i tam jest napisane, że encje w HTML 
używają normy ISO 10646, czyli właśnie Unicode. Szybki test w postaci 
Ą daje "Ą", a więc potwierdza, że to Twoje numerki wygrywają :).


-- 
Pozdrawiam/Regards - Bogdan                     (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux):            http://bogdro.evai.pl
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.Xiph.org www.TorProject.org  Soft(EN): http://bogdro.evai.pl/soft

Użytkownik "Bogdan (bogdro)"  napisał:

> Teraz patrzę na normę HTML i tam jest napisane, że encje w HTML używają 
> normy ISO 10646, czyli właśnie Unicode. Szybki test w postaci Ą daje 
> "Ą", a więc potwierdza, że to Twoje numerki wygrywają :).

Dzięki za odpowiedź. Całość przeczytam i zrozumiem (może) już jutro. Na 
dzisiaj muszę skończyć. Tak naprawdę nie chodzi o normy HTML, ale o 
prawidłowe skonstruowanie programu. Tablice znaków zawsze można zmienić bez 
problemu. Ewentualnie zrobić wersje.

Pozdrawiam 

Użytkownik "Kamil"  napisał:

> prawidłowe skonstruowanie programu.

Jako debuggera używałem SoftIce, który działa tylko w Win 98 i niższych. W 
XP już nie chce. Jest coś podobnego pod XP?

Pzdr 

Użytkownik "Kamil"  napisał:

>>  prawidłowe skonstruowanie programu.

Czarno to widzę. Pliterek jest 18 i każda w UTF 8 ma 6 znaków. Po pierwszym 
przeszukaniu i zapisaniu do pliku, ten plik się zmieni/wydłuży, a więc 
wszystkie dotychczasowe adresy się zmienią. W takim razie trzeba wczytać ten 
nowy plik i przeszukać, oraz zapisać do pliku kolejny znak. I tak 18 razy. 
Można to zrobić inaczej?

Pzdr 

W dniu 24.03.2022 o 13:59, Kamil pisze:
> Użytkownik "Kamil"  napisał:
> 
>>>  prawidłowe skonstruowanie programu.
> 
> Czarno to widzę. Pliterek jest 18 i każda w UTF 8 ma 6 znaków. Po 
> pierwszym przeszukaniu i zapisaniu do pliku, ten plik się 
> zmieni/wydłuży, a więc wszystkie dotychczasowe adresy się zmienią. W 
> takim razie trzeba wczytać ten nowy plik i przeszukać, oraz zapisać do 
> pliku kolejny znak. I tak 18 razy. Można to zrobić inaczej?
> 
> Pzdr


Krótka odpowiedź: tak :).

Trochę dłuższa (jeden ze sposobów, pewnie są lepsze):

1) czytasz plik znak po znaku (albo od razu cały plik do bufora w 
pamięci, przez który potem przechodzisz znak po znaku),

2) jeśli odczytanym znakiem nie trzeba się zajmować, przepisujesz go 
do bufora wyjściowego bez zmian,

3) jeśli odczytany znak trzeba zmienić, zapisujesz do bufora 
wyjściowego "to, co trzeba",

4) do pliku zapisujesz bufor wyjściowy jako całą zawartość, bez 
przeskakiwania co gdzie trzeba zmienić.

-- 
Pozdrawiam/Regards - Bogdan                     (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux):            http://bogdro.evai.pl
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.Xiph.org www.TorProject.org  Soft(EN): http://bogdro.evai.pl/soft

Użytkownik "Kamil" <nospam@tlen.pl> napisał w wiadomości news:623b0844$0$493$65785112@news.neostrada.pl...
> Użytkownik "Kamil"  napisał:
>
>> prawidłowe skonstruowanie programu.
>
> Jako debuggera używałem SoftIce, który działa tylko w Win 98 i niższych. W XP już nie chce. Jest coś podobnego pod XP?

Syser, chociaż powinien wystarczyć OllyDbg (chyba, że biegasz po ringu 0) 

Użytkownik "Radoslaw Szwed"  napisał:

> Syser

Dzięki za nazwę programu.

> chociaż powinien wystarczyć OllyDbg (chyba, że biegasz po ringu 0)

OllyDbg to jest debugger? To jakieś dziwadło, które niewiele potrafi.

Pzdr 

Użytkownik "Bogdan (bogdro)"  napisał:

> 1) czytasz plik znak po znaku (albo od razu cały plik do bufora w pamięci, 
> przez który potem przechodzisz znak po znaku),

> 2) jeśli odczytanym znakiem nie trzeba się zajmować, przepisujesz go do 
> bufora wyjściowego bez zmian,

> 3) jeśli odczytany znak trzeba zmienić, zapisujesz do bufora wyjściowego 
> "to, co trzeba",

> 4) do pliku zapisujesz bufor wyjściowy jako całą zawartość, bez 
> przeskakiwania co gdzie trzeba zmienić.

Opisałeś dokładnie to samo co ja wcześniej. To jest proste i ładnie działa 
dla jednego znaku. Natomiast potencjalnie w pliku tych znaków jest 18. 
Procedura podczas jednego przebiegu wyszukuje jeden znak. Nie może więcej, 
bo zmienią się liczniki. Nie wiem, czy opisałem to zrozumiale. Jeśli by 
procedura mogła szukać wszystkich znaków trzeba by było wprowadzić zmienne 
zawierające wartości liczników, korygowane po każdym znalezionym znaku. To 
skomplikowane i niepewne.

Pzdr 

Użytkownik "Kamil"  napisał:

............

Wpadłem na pomysł, aby na UTF 8 zamieniać wszystkie znaki w pliku :)

Ciekawe co na to powie przeglądarka?

Pzdr 

W dniu 25.03.2022 o 22:47, Kamil pisze:
> Użytkownik "Bogdan (bogdro)"  napisał:
> 
>> 1) czytasz plik znak po znaku (albo od razu cały plik do bufora w 
>> pamięci, przez który potem przechodzisz znak po znaku),
> 
>> 2) jeśli odczytanym znakiem nie trzeba się zajmować, przepisujesz go 
>> do bufora wyjściowego bez zmian,
> 
>> 3) jeśli odczytany znak trzeba zmienić, zapisujesz do bufora 
>> wyjściowego "to, co trzeba",
> 
>> 4) do pliku zapisujesz bufor wyjściowy jako całą zawartość, bez 
>> przeskakiwania co gdzie trzeba zmienić.
> 
> Opisałeś dokładnie to samo co ja wcześniej. To jest proste i ładnie 
> działa dla jednego znaku. Natomiast potencjalnie w pliku tych znaków 
> jest 18. Procedura podczas jednego przebiegu wyszukuje jeden znak. Nie 
> może więcej, bo zmienią się liczniki. Nie wiem, czy opisałem to 
> zrozumiale. Jeśli by procedura mogła szukać wszystkich znaków trzeba 
> by było wprowadzić zmienne zawierające wartości liczników, korygowane 
> po każdym znalezionym znaku. To skomplikowane i niepewne.
> 
> Pzdr


  Tak, opisałeś zrozumiale. Tzn. wiem, o jaki problem chodzi. Tyle, 
ile rozumiem, to to, że masz bufor z danymi z pliku, zmieniasz znak na 
encję HTML, ale to powoduje "przesunięcie" się pozostałych znaków z 
pliku, więc musisz szukać pod innymi numerami. Tak by to było, gdyby 
używać jednego i tego samego bufora na wejście i wyjście i gdyby 
przerabiać jedną literę na raz.
  Ja zaś proponuję 2 OSOBNE bufory. Pierwszy, wejściowy, zawiera 
odczytane dane z pliku (lub po prostu czytasz ten plik na bieżąco). 
Chodzisz w nim znak po znaku. Jak znajdziesz znak, który trzeba 
zamienić (jeden z 18), to do bufora wyjściowego zapisujesz podmienioną 
wersję, podbijasz indeks/wskaźnik/licznik wyjściowy o 6 (długość encji 
HTML), a wejściowy - ciągle o 1. Ma to, według tego pomysłu, wyglądać 
mniej-więcej tak:

wejście: aąbcć
indeks do bufora/pliku wejściowego: 0, 1, 2, 3, 4, 5

wyjście: a&#AAA;bc&#AAA;
indeks do bufora/pliku wyjściowego: 0, 1, 7, 8, 9, 15

  No i drugą istotną ideą jest to, że każdy przeczytany znak 
porównujesz z 18 wzorcami i w związku z tym od razu generujesz 
kompletny wynik, zamiast najpierw zamieniać wszystkie "ą", potem 
wszystkie "ć" itd., bo to faktycznie oznacza problemy z indeksami, 
cofanie się w buforze, zamazywanie sobie samemu danych itd.

-- 
Pozdrawiam/Regards - Bogdan                     (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux):            http://bogdro.evai.pl
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.Xiph.org www.TorProject.org  Soft(EN): http://bogdro.evai.pl/soft

Użytkownik "Bogdan (bogdro)"  napisał:

> Tak, opisałeś zrozumiale. Tzn. wiem, o jaki problem chodzi. Tyle, ile 
> rozumiem, to to, że masz bufor z danymi z pliku, zmieniasz znak na encję 
> HTML, ale to powoduje "przesunięcie" się pozostałych znaków z pliku, więc 
> musisz szukać pod innymi numerami. Tak by to było, gdyby używać jednego i 
> tego samego bufora na wejście i wyjście i gdyby przerabiać jedną literę na 
> raz.

>  Ja zaś proponuję 2 OSOBNE bufory. ...

Mam dwa bufory, jeden wejściowy i drugi wyjściowy. I chodzi o to, że jeśli 
przeszukam bufor wejściowy jednym znakiem i zapiszę do bufora wyjściowego to 
muszę dla procedury przeszukiwania wejścia kolejnym znakiem i jego 
zapisywania do wyjścia ustawić odpowiednio adresy. A skąd ma program 
"wiedzieć na jakiej pozycji znajduje się ten aktualnie znaleziony i 
zapisywany znak? Chyba, że czegoś nie rozumiem. Pogłówkuję jeszcze i może mi 
się rozjaśni. Póki co jedynym wyjściem wydaje mi się wbudowanie w program 
kolejnej procedury ReadFile i kolejnego zestawu buforów.

Pzdr 

W dniu 26.03.2022 o 17:38, Kamil pisze:
> Użytkownik "Bogdan (bogdro)"  napisał:
> 
>> Tak, opisałeś zrozumiale. Tzn. wiem, o jaki problem chodzi. Tyle, 
>> ile rozumiem, to to, że masz bufor z danymi z pliku, zmieniasz znak 
>> na encję HTML, ale to powoduje "przesunięcie" się pozostałych znaków 
>> z pliku, więc musisz szukać pod innymi numerami. Tak by to było, 
>> gdyby używać jednego i tego samego bufora na wejście i wyjście i 
>> gdyby przerabiać jedną literę na raz.
> 
>>  Ja zaś proponuję 2 OSOBNE bufory. ...
> 
> Mam dwa bufory, jeden wejściowy i drugi wyjściowy. I chodzi o to, że 
> jeśli przeszukam bufor wejściowy jednym znakiem i zapiszę do bufora 
> wyjściowego to muszę dla procedury przeszukiwania wejścia kolejnym 
> znakiem i jego zapisywania do wyjścia ustawić odpowiednio adresy. A 
> skąd ma program "wiedzieć na jakiej pozycji znajduje się ten aktualnie 
> znaleziony i zapisywany znak? Chyba, że czegoś nie rozumiem. 
> Pogłówkuję jeszcze i może mi się rozjaśni. Póki co jedynym wyjściem 
> wydaje mi się wbudowanie w program kolejnej procedury ReadFile i 
> kolejnego zestawu buforów.
> 
> Pzdr


  I to jest właśnie to, co poruszyłem w mojej "drugiej istotnej idei": 
przeszukujesz bufor wejściowy znak po znaku, ale po JEGO znaku, a NIE 
po znaku, który przerabiasz (tj. "ą", "ć", ...).
  Jeśli przerabiasz najpierw wszystkie "ą", potem wszystkie "ć", potem 
"ę" itd., to faktycznie tworzy to problemy, o których obaj mówimy - 
jak "wiedzieć", gdzie teraz zapisać wynik.

  Ja zaś proponuję coś, co można by zapisać pseudokodem:

odczytać plik wejściowy do bufora input

i = 0;  // indeks do bufora wejściowego
o = 0;  // indeks do bufora wyjściowego

while i < długość input
	if input[i] = 'ą'
		output[o] = "&#XXX;";
		o = o + 6;
	else if input[i] = 'ć'
		output[o] = "&#XXX;";
		o = o + 6;
	...
	else if input[i] = 'Ż'
		output[o] = "&#XXX;";
		o = o + 6;
	else
		output[o] = input[i];
		o = o + 1;

	i = i + 1;
end while

zapisać bufor output do pliku wyjściowego

Dzięki takiemu podejściu nie musisz za każdą nową literą zaczynać znów 
zapisywać do output i uważać, pod jaki adres zapisujesz (tj. pamiętać, 
ile zmienionych liter było już do tej pory).

-- 
Pozdrawiam/Regards - Bogdan                     (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux):            http://bogdro.evai.pl
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.Xiph.org www.TorProject.org  Soft(EN): http://bogdro.evai.pl/soft

Użytkownik "Bogdan (bogdro)"  napisał:

>  I to jest właśnie to, co poruszyłem w mojej "drugiej istotnej idei": 
> przeszukujesz bufor wejściowy znak po znaku, ale po JEGO znaku, a NIE po 
> znaku, który przerabiasz (tj. "ą", "ć", ...).

Co to znaczy "przeszukujesz"? Czytam znak po znaku porównując go z założonym 
kryterium. Jeśli warunek nie jest spełniony, zapisuję znak bez zmian, a 
jeśli spełniony zapisuję znak w postaci jego reprezentacji w UTF 8.

> Jeśli przerabiasz najpierw wszystkie "ą", potem wszystkie "ć", potem "ę" 
> itd., to faktycznie tworzy to problemy, o których obaj mówimy -
j> ak "wiedzieć", gdzie teraz zapisać wynik.

>  Ja zaś proponuję coś, co można by zapisać pseudokodem:

> odczytać plik wejściowy do bufora input

> i = 0;  // indeks do bufora wejściowego
> o = 0;  // indeks do bufora wyjściowego

> while i < długość input
> if input[i] = 'ą'
> output[o] = "&#XXX;";
> o = o + 6;
> else if input[i] = 'ć'
> output[o] = "&#XXX;";
> o = o + 6;
> .....
> end while

> zapisać bufor output do pliku wyjściowego

> Dzięki takiemu podejściu nie musisz za każdą nową literą zaczynać znów 
> zapisywać do output i uważać, pod jaki adres zapisujesz (tj. pamiętać, ile 
> zmienionych liter było już do tej pory).

To już opisałem wcześniej:

Jeśli by procedura mogła szukać wszystkich znaków trzeba by było wprowadzić
zmienne zawierające wartości liczników, korygowane po każdym znalezionym 
znaku.
To skomplikowane i niepewne.

Spróbuję tak zrobić i sprawdzić działanie. Dlatego pytałem o debugger, abym 
mógł znaleźć błędne miejsca. A pętla zrobiona "ręcznie", czy w postaci 
makroinstrukcji działa tak samo. Może uda mi się wykorzystać podany przez 
Ciebie sposób. Dzięki za kod.

Pzdr

W dniu 28.03.2022 o 09:36, Kamil pisze:
> Użytkownik "Bogdan (bogdro)"  napisał:
> 
>>  I to jest właśnie to, co poruszyłem w mojej "drugiej istotnej 
>> idei": przeszukujesz bufor wejściowy znak po znaku, ale po JEGO 
>> znaku, a NIE po znaku, który przerabiasz (tj. "ą", "ć", ...).
> 
> Co to znaczy "przeszukujesz"? Czytam znak po znaku porównując go z 
> założonym kryterium. Jeśli warunek nie jest spełniony, zapisuję znak 
> bez zmian, a jeśli spełniony zapisuję znak w postaci jego 
> reprezentacji w UTF 8.


Tak.


>> Jeśli przerabiasz najpierw wszystkie "ą", potem wszystkie "ć", potem 
>> "ę" itd., to faktycznie tworzy to problemy, o których obaj mówimy -
> j> ak "wiedzieć", gdzie teraz zapisać wynik.
> 
>>  Ja zaś proponuję coś, co można by zapisać pseudokodem:
> 
>> odczytać plik wejściowy do bufora input
> 
>> i = 0;  // indeks do bufora wejściowego
>> o = 0;  // indeks do bufora wyjściowego
> 
>> while i < długość input
>> if input[i] = 'ą'
>> output[o] = "&#XXX;";
>> o = o + 6;
>> else if input[i] = 'ć'
>> output[o] = "&#XXX;";
>> o = o + 6;
>> .....
>> end while
> 
>> zapisać bufor output do pliku wyjściowego
> 
>> Dzięki takiemu podejściu nie musisz za każdą nową literą zaczynać 
>> znów zapisywać do output i uważać, pod jaki adres zapisujesz (tj. 
>> pamiętać, ile zmienionych liter było już do tej pory).
> 
> To już opisałem wcześniej:
> 
> Jeśli by procedura mogła szukać wszystkich znaków trzeba by było 
> wprowadzić
> zmienne zawierające wartości liczników, korygowane po każdym 
> znalezionym znaku.


Tak, to co nazwałem "i" oraz "o" w pseudo-kodzie.


> To skomplikowane i niepewne.


Co kto lubi. Mi łatwiej sterować dwiema zmiennymi do dwóch buforów, 
niż mieć jedną i "jeździć" z nią w przód i w tył. Jeśli inny sposób 
będzie dla Ciebie wygodniejszy, to go użyj.

[...]


-- 
Regards - Bogdan ('bogdro') D.                 (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):    http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org

Użytkownik "Bogdan (bogdro)"  napisał:

>> To skomplikowane i niepewne.

> Co kto lubi. Mi łatwiej sterować dwiema zmiennymi do dwóch buforów, niż 
> mieć jedną i "jeździć" z nią w przód i w tył. Jeśli inny sposób będzie dla 
> Ciebie wygodniejszy, to go użyj.

Już napisałem, że mam dwa bufory próbuję skonstruować procedurę prawie 
identyczną z podaną przez Ciebie.

Z pewnymi niewielkimi zmianami, bo ta Twoja "surowa" nie zadziała dobrze. 
Tak myślę analizując kod na "sucho". A, że Ty jesteś w tym o wiele lepszy 
ode mnie, więc raczej Ty masz rację :0

pzdr