Sprawdzanie Kodowania Znaków

[Zagiewa]

Istnieje jakikolwiek program sprawdzający kodowanie znaków w plikach .txt .doc .html .php itp. itd.? Może to być najprostszy program/wtyczka, cokolwiek co by mi tylko powiedziało, że dany plik ma takie lub takie kodowanie.

[qmic]

Istnieje jakikolwiek program sprawdzający kodowanie znaków w plikach .txt .doc .html .php itp. itd.? Może to być najprostszy program/wtyczka, cokolwiek co by mi tylko powiedziało, że dany plik ma takie lub takie kodowanie.

 

enca

[jjj]

Jednoznacznie: nie da się. Bezbłędnie: też nie.

 

Pierwsze przybliżenie dla plików tekstowych:

file nazwa

 

Rozsądnie wyglądające narzędzie: http://chardet.feedparser.org/

Jest to port komponentu autodetekcji kodowania tekstu z Netscape do Pythona. Ma postać modułu bibliotecznego, użycie wymaga napisania skryptu w Pythonie. Nazwisko autora (Mark Pilgrim) sugeruje bardzo solidną robotę.

 

Pliki inne niż tekstowe, xml itp: będzie ciężko

[qmic]

Jednoznacznie: nie da się. 100% pewności też nie.

 

Da się, napisałem programik w pythonie do tego, jak do tej pory a przerobił już ponad kilkadziesiąt maili i skuteczność ma 100% z tego co wiem, ale trzeba by było go przerobić do działania samodzielnego jako program (jest to część większego projektu). Nigdy tego jednak nie potrzebowałem, bo enca sobie radzi bardzo dobrze, ew. gedit też bardzo dobrze to robi.

 

 

[Zagiewa]

Nigdy nie programowałem w Pythonie więc myślę, że za dużo z tym zachodu aby sprawdzał mi tylko pliki tekstowe. Mój problem z kodowaniem znaków pojawił się gdy zostałem zmuszony konkretne pliki stale edytować na kilku różnych kompach/systemach/edytorach teksty - prawie każdy z nich używa innego kodowanie przez co za każdym razem jak uruchomiłem plik wyglądał on inaczej Chciał bym po prostu sprawdzić kodowanie pliku przed jego edycja tak żebym mógł wcześniej zmienić sobie kodowanie znaków w edytorze tekstu na którym w danych chwili przyjdzie mi pracować.

 

Co do enca to zaraz go sprawdzę bo według krótkiego opisu jaki znalazłem na google wydaje się być tym czego szukam

 

Ok. to do czego doszedłem... enca sprawdza się bardzo fajnie więc dzięki qmic za pomoc Sprawdzałem pliki o rozszerzeniach .txt .doc .php .html .css. Z plikami .txt radzi sobie najlepiej. Ma tylko problem z plikami .doc - wypluwa:

 

[Zagiewa@zagiewa ~]$ enca -fd /home/Zagiewa/regulamin.doc
/home/Zagiewa/regulamin.doc: Unrecognized encoding
  Failure reason: Sample is just garbage.

[qmic]

/home/Zagiewa/regulamin.doc: Unrecognized encoding

Failure reason: Sample is just garbage.[/code]

 

Proszę ,

Co do plików doc to nie jest plik tekstowy, tylko binarny - stąd problem, ale po co rozpoznawać kodowanie w pliku doc? Tam się go nie rozpoznaje, ono jest ustawione.

Jeszcze się nie spotkałem aby w pliku doc nie było polskich znaków ? Chyba że ktoś tam wkleił plik tekstowy bez polskich znaków

[jjj]

Mówiłem, że będą problemy. Dla takich plików musisz mieć algorytm interpretujący dany format. Co nie znaczy, że tekst zaszyty wewnątrz doc-a nie jest kodowany. Bo jest. Istnieją doc-e z kodowaniem 8-bitowym (np. cp-1250) i utf-16.

 

@qmic. Skoro już się odezwałem: rozpoznawanie kodu ma podstawy heurystyczne. Nie ma w 100% teoretycznie bezbłędnego algorytmu rozpoznawania. Mimo to: a) działający program może okazać się skuteczny w 100% Twoich i moich przypadków; teoretyczna skuteczność na poziomie absolutnej pewności nie jest niezbędna w rozwiązywaniu problemów tego typu (choćby dlatego, że tekst może zawierać błędne znaki).

 

offtopic: co byście powiedzieli na rozpoznawanie efektów ,,iterowanej konwersji'': ciąg wejściowy utf-8 interpretujemy jako cp-1250, po czym efekt interpretacji zapisujemy w kodowaniu ... Wbrew pozorom, tzw. ZU są w stanie coś takiego wyprodukować przy pomocy przeglądarki i schowka.

[qmic]

Mówiłem, że będą problemy. Dla takich plików musisz mieć algorytm interpretujący dany format. Co nie znaczy, że tekst zaszyty wewnątrz doc-a nie jest kodowany. Bo jest. Istnieją doc-e z kodowaniem 8-bitowym (np. cp-1250) i utf-16.

 

@qmic. Skoro już się odezwałem: rozpoznawanie kodu ma podstawy heurystyczne. Nie ma w 100% teoretycznie bezbłędnego algorytmu rozpoznawania. Mimo to: a) działający program może okazać się skuteczny w 100% Twoich i moich przypadków; teoretyczna skuteczność na poziomie absolutnej pewności nie jest niezbędna w rozwiązywaniu problemów tego typu (choćby dlatego, że tekst może zawierać błędne znaki).

 

offtopic: co byście powiedzieli na rozpoznawanie efektów ,,iterowanej konwersji'': ciąg wejściowy utf-8 interpretujemy jako cp-1250, po czym efekt interpretacji zapisujemy w kodowaniu ... Wbrew pozorom, tzw. ZU są w stanie coś takiego wyprodukować przy pomocy przeglądarki i schowka.

 

O jakim algorytmie mówisz? Pliki doc to format binarny co to ma kodowanie do rzeczy ?

Mowa była o kodowaniu formatów tekstowych, kodowanie plików binarnych takich jak .doc to już inna bajka i zajmuje się tym już interpreter (np. Word) i on sobie tam koduje znaki po swojemu.

 

Na jakiej podstawie wnosisz że nie ma 100% bezbłędnego algorytmu rozpoznawania? Liczba możliwych sposób zapisania znaków jest skończona i dająca się przeanalizować w określonym czasie, jak do tego dodamy metody słownikowe to już mamy 100%

 

Co do offtopicu to nie tylko ZU potrafią tak zrobić, ostatnio dostałem do migracji serwer MySQL 3 i mam z niego zrobić MySQL 5, a admin tam tak wykombinował że baza jest w latin1 (ISO-8859-1), transmisja danych pomiędzy bazą danych a tomcatem w ISO-8859-2, a strona w UTF-8, potrafiłbyś tak ?

 

 

 

 

 

[jjj]

O jakim algorytmie mówisz?

o interpreterze formatu.

Liczba możliwych sposób zapisania znaków jest skończona i dająca się przeanalizować w określonym czasie,

tak, ale liczba możliwych tekstów już nie. Zaś jeżeli weźmiesz pod uwagę, że mając tekst nie znasz jego znaczenia, że teksty mogą zawierać błędy kodowania i błędy słownikowe, itp. -- do oczywistości robi się daleko. Oczywiście, istnieją heurystyki całkiem skuteczne *w praktyce*, ale przez 100% rozumiem logiczny dowód deterministycznej 100% skutecznosci. Bez deprecjonowania nikogo i niczego.